perm filename RHT.MSG[CMU,AIL] blob
sn#129496 filedate 1974-11-13 generic text, type T, neo UTF8
∂12-NOV-74 0730 CMU,AIL @ CMU
Russ,
I have no argument with anything in your last msg.
Technically, I think the proposed changes are good; and since you
are much more knowledgable and familiar with this, I would certainly
bow to your judgment anyway.
I have not done the SETPRI stuff yet, and if you could get it done
in the next couple of days, I would be most grateful to wait and
snarf yours. A bit in the SPROUT sounds just fine to me.
Again, I certainly must go along with your perceptions about
maintenance. I think we will probably hold off on SAIL-8 for
a while yet, mostly because we are in crisis mode now and I
have no time. (I assume that the changes for FIFO will be directly
usable in SAIL-7 -- if not, we may be forced to go over sooner,
I guess [but I hope not]).
I would suggest trying to get me over the net before calling -- I will
probably be unavailable for most of the day (Nils Nilsson is giving
a talk later, etc.). You can always do a PLEASE to the
to the operator, or just do a SEND to some random A610 job.
Peace,
Lee
p.s. must run now, but will check my mail later.
∂11-NOV-74 0729 network site CMU
***** FTP mail from [A610LE03] (ERMAN)
Russ,
Thanks for the quick response to my poke about scheduling processes.
Random reactions:
.We also thought of using events and doing our own scheduling,
but were hoping
for something a bit more efficient (and less indirect).
.I would be somewhat frightened about going to an undocumented
implementation of a much older, documented, and debugged facility. This
is especially true since there is no one, anywhere, that is responsible
for and has the time to do the debugging. It seems to me that unless
you are able to commit whatever of you is necessary to respond to
bug reports on such a new implementation and document the record stuff,
that it would be very unfair to the rest of the SAIL world. If you
just put it up as an "experimental" system, with no guarantees, then
we will be back in the same boat as before, caught between your system
which we dare not use and the "X,AIL" system in which bugs never get
fixed.
....I would strongly urge making some attempt to get some
resources from somewhere committed to maintaining SAIL -- I know we
would be willing to kick in some of our ARPA funding to help.
The situation as it now exists is inefficient and unfair for all
of us (especially including you people). If you think it would help,
we would be glad to make a poke at someone to voice this concern.
Who is the right person there? McCarthy? (I doubt it.) Binford?
I will not do anything about this for now until I hear from you,
so don't panic.
thanx again for your help,
Lee
P.S. I guess we will just go change SETPRI for now; if you have any
ramore random thoughts about these changes, please let me know.
-----
∂10-NOV-74 1607 network site CMU
***** FTP mail from [A610LE03] (ERMAN)
Russ,
We are hot and heavy into using the PROCESS stuff. One thing we
notice is that sprouted processes get put on their respective
priority lists in LIFO order. We would really like it to be
FIFO. Is there some reasonable way we can impose our own
(user) schedule in place of SAIL's (which would, obviously,
give us even more flesibilty)? I gather there is no facility
akin to user CAUSE and INTERROGATE procedures. Would you have
a suggestion on a simple way to implement this? If not, which
piece of the run-times would you suggest we should change to
get SAIL to do FIFO (i.e., putting on the queue or taking off)?
thanx for any help you can offer,
Lee and Rick